Feature/flatpak update portal #117
Conversation
WalkthroughThe changes introduce Flatpak update integration for the Linux distribution of the application. The Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Note 🔌 MCP (Model Context Protocol) integration is now available in Early Access!Pro users can now connect to remote MCP servers under the Integrations page to get reviews and chat conversations that understand additional development context. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (2)
src/main/java/org/cryptomator/linux/update/FlatpakUpdater.java (2)
49-52: Remove redundant CreateUpdateMonitor call in constructor.The
CreateUpdateMonitorcall in the constructor appears redundant as it's called again ingetUpdateMonitor()method, and its return value is ignored here.public FlatpakUpdater() { this.portal = new UpdatePortal(); - portal.CreateUpdateMonitor(UpdatePortal.OPTIONS_DUMMY); }
173-193: Consider extracting a helper method to reduce code duplication.The pattern of extracting string values from variants is repeated multiple times.
+private String extractStringFromVariant(Map<String, Variant<?>> map, String key) { + Variant<?> variant = map.get(key); + return variant != null ? (String) variant.getValue() : ""; +} + private void notifyOnUpdateAvailable(Flatpak.UpdateMonitor.UpdateAvailable signal) { - String remoteCommit = ""; - Variant<?> remoteCommitVariant = signal.update_info.get("remote-commit"); - if (null != remoteCommitVariant) { - remoteCommit = (String) remoteCommitVariant.getValue(); - } - String runningCommit = ""; - Variant<?> runningCommitVariant = signal.update_info.get("running-commit"); - if (null != runningCommitVariant) { - runningCommit = (String) runningCommitVariant.getValue(); - } - String localCommit = ""; - Variant<?> localCommitVariant = signal.update_info.get("local-commit"); - if (null != localCommitVariant) { - localCommit = (String) localCommitVariant.getValue(); - } + String remoteCommit = extractStringFromVariant(signal.update_info, "remote-commit"); + String runningCommit = extractStringFromVariant(signal.update_info, "running-commit"); + String localCommit = extractStringFromVariant(signal.update_info, "local-commit"); UpdateAvailable updateAvailable = new UpdateAvailable(runningCommit, localCommit, remoteCommit); for (UpdateAvailableListener listener : updateAvailableListeners) { listener.onUpdateAvailable(updateAvailable); } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
pom.xml(2 hunks)src/main/java/module-info.java(2 hunks)src/main/java/org/cryptomator/linux/update/FlatpakUpdater.java(1 hunks)src/main/resources/META-INF/services/org.cryptomator.integrations.update.UpdateService(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
src/main/java/module-info.java (1)
Learnt from: infeo
PR: #80
File: src/main/java/org/cryptomator/linux/autostart/FreedesktopAutoStartService.java:56-62
Timestamp: 2024-07-16T22:36:32.769Z
Learning: For the FreedesktopAutoStartService in the Cryptomator project, exceptions are preferred to contain all necessary debugging information without additional logging before throwing them.
src/main/java/org/cryptomator/linux/update/FlatpakUpdater.java (1)
Learnt from: infeo
PR: #80
File: src/main/java/org/cryptomator/linux/autostart/FreedesktopAutoStartService.java:56-62
Timestamp: 2024-07-16T22:36:32.769Z
Learning: For the FreedesktopAutoStartService in the Cryptomator project, exceptions are preferred to contain all necessary debugging information without additional logging before throwing them.
🔇 Additional comments (4)
src/main/resources/META-INF/services/org.cryptomator.integrations.update.UpdateService (1)
1-1: LGTM!The service provider configuration correctly registers the
FlatpakUpdaterimplementation.pom.xml (2)
43-43: Verify the use of SNAPSHOT version for production readiness.The PR depends on a SNAPSHOT version of
integrations-api. If this PR is intended for production, consider waiting for the stable release of version 1.7.0.
46-46: LGTM!The new Flatpak update portal dependency is properly configured with a stable version.
Also applies to: 92-96
src/main/java/module-info.java (1)
6-6: LGTM!The module configuration correctly integrates the new Flatpak update service with proper dependencies, service provisions, and package access.
Also applies to: 9-9, 14-14, 22-22, 31-31, 36-36
| public UpdateCheckerTask getLatestReleaseChecker(DistributionChannel.Value channel) { | ||
| if (channel != DistributionChannel.Value.LINUX_FLATPAK) { | ||
| LOG.error("Wrong channel provided: {}", channel); | ||
| return null; | ||
| } | ||
| portal.setUpdateCheckerTaskFor(APP_NAME); | ||
| return portal.getUpdateCheckerTaskFor(APP_NAME); | ||
| } |
There was a problem hiding this comment.
Throw exception instead of returning null for invalid channel.
Returning null for an invalid channel could lead to NullPointerException in the calling code. Consider throwing an IllegalArgumentException instead.
@Override
public UpdateCheckerTask getLatestReleaseChecker(DistributionChannel.Value channel) {
if (channel != DistributionChannel.Value.LINUX_FLATPAK) {
- LOG.error("Wrong channel provided: {}", channel);
- return null;
+ throw new IllegalArgumentException("Wrong channel provided: " + channel + ". Expected: LINUX_FLATPAK");
}
portal.setUpdateCheckerTaskFor(APP_NAME);
return portal.getUpdateCheckerTaskFor(APP_NAME);
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| public UpdateCheckerTask getLatestReleaseChecker(DistributionChannel.Value channel) { | |
| if (channel != DistributionChannel.Value.LINUX_FLATPAK) { | |
| LOG.error("Wrong channel provided: {}", channel); | |
| return null; | |
| } | |
| portal.setUpdateCheckerTaskFor(APP_NAME); | |
| return portal.getUpdateCheckerTaskFor(APP_NAME); | |
| } | |
| @Override | |
| public UpdateCheckerTask getLatestReleaseChecker(DistributionChannel.Value channel) { | |
| if (channel != DistributionChannel.Value.LINUX_FLATPAK) { | |
| throw new IllegalArgumentException("Wrong channel provided: " + channel + ". Expected: LINUX_FLATPAK"); | |
| } | |
| portal.setUpdateCheckerTaskFor(APP_NAME); | |
| return portal.getUpdateCheckerTaskFor(APP_NAME); | |
| } |
🤖 Prompt for AI Agents
In src/main/java/org/cryptomator/linux/update/FlatpakUpdater.java around lines
60 to 67, the method getLatestReleaseChecker returns null when an invalid
channel is provided, which risks causing NullPointerExceptions. Replace the null
return with throwing an IllegalArgumentException that clearly states the channel
is invalid. This change ensures callers are immediately informed of the misuse
and can handle the error properly.
| public void triggerUpdate() throws UpdateFailedException { | ||
| var monitor = getUpdateMonitor(); | ||
| portal.updateApp("x11:0", monitor, UpdatePortal.OPTIONS_DUMMY); | ||
| } |
There was a problem hiding this comment.
Avoid hardcoding the display parameter.
The hardcoded "x11:0" display parameter may not work correctly in Wayland environments or other display configurations.
Consider obtaining the display parameter dynamically:
@Override
public void triggerUpdate() throws UpdateFailedException {
var monitor = getUpdateMonitor();
- portal.updateApp("x11:0", monitor, UpdatePortal.OPTIONS_DUMMY);
+ String display = System.getenv("DISPLAY");
+ if (display == null || display.isEmpty()) {
+ display = System.getenv("WAYLAND_DISPLAY");
+ if (display != null && !display.isEmpty()) {
+ display = "wayland:" + display;
+ } else {
+ display = "x11:0"; // fallback
+ }
+ }
+ portal.updateApp(display, monitor, UpdatePortal.OPTIONS_DUMMY);
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| public void triggerUpdate() throws UpdateFailedException { | |
| var monitor = getUpdateMonitor(); | |
| portal.updateApp("x11:0", monitor, UpdatePortal.OPTIONS_DUMMY); | |
| } | |
| @Override | |
| public void triggerUpdate() throws UpdateFailedException { | |
| var monitor = getUpdateMonitor(); | |
| String display = System.getenv("DISPLAY"); | |
| if (display == null || display.isEmpty()) { | |
| display = System.getenv("WAYLAND_DISPLAY"); | |
| if (display != null && !display.isEmpty()) { | |
| display = "wayland:" + display; | |
| } else { | |
| display = "x11:0"; // fallback | |
| } | |
| } | |
| portal.updateApp(display, monitor, UpdatePortal.OPTIONS_DUMMY); | |
| } |
🤖 Prompt for AI Agents
In src/main/java/org/cryptomator/linux/update/FlatpakUpdater.java around lines
70 to 73, the display parameter "x11:0" is hardcoded in the portal.updateApp
call, which can cause issues in Wayland or other display environments. Modify
the code to dynamically obtain the display parameter from the environment or
system properties instead of using a fixed string. Replace the hardcoded "x11:0"
with a variable that retrieves the current display setting at runtime.
| @Override | ||
| public void close() throws Exception { | ||
| try { | ||
| if (null != updateMonitor) { | ||
| portal.cancelUpdateMonitor(updateMonitor); | ||
| } | ||
| portal.close(); | ||
| } catch (Exception e) { | ||
| LOG.error(e.toString(), e.getCause()); | ||
| } | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Improve exception handling in close method.
The current implementation catches a generic Exception and the logging could be more informative.
@Override
public void close() throws Exception {
try {
if (null != updateMonitor) {
portal.cancelUpdateMonitor(updateMonitor);
}
portal.close();
- } catch (Exception e) {
- LOG.error(e.toString(), e.getCause());
+ } catch (DBusException e) {
+ LOG.error("Failed to close DBus connection properly", e);
+ throw e;
+ } catch (Exception e) {
+ LOG.error("Unexpected error during resource cleanup", e);
+ throw e;
}
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| @Override | |
| public void close() throws Exception { | |
| try { | |
| if (null != updateMonitor) { | |
| portal.cancelUpdateMonitor(updateMonitor); | |
| } | |
| portal.close(); | |
| } catch (Exception e) { | |
| LOG.error(e.toString(), e.getCause()); | |
| } | |
| } | |
| @Override | |
| public void close() throws Exception { | |
| try { | |
| if (null != updateMonitor) { | |
| portal.cancelUpdateMonitor(updateMonitor); | |
| } | |
| portal.close(); | |
| } catch (DBusException e) { | |
| LOG.error("Failed to close DBus connection properly", e); | |
| throw e; | |
| } catch (Exception e) { | |
| LOG.error("Unexpected error during resource cleanup", e); | |
| throw e; | |
| } | |
| } |
🤖 Prompt for AI Agents
In src/main/java/org/cryptomator/linux/update/FlatpakUpdater.java around lines
98 to 108, improve the exception handling in the close method by catching more
specific exceptions if possible, and enhance the logging to provide a clearer
and more informative message. Instead of logging e.toString() and e.getCause()
separately, log the full exception with its stack trace to capture complete
context for debugging.
| private void notifyOnUpdateProceeds(Flatpak.UpdateMonitor.Progress signal) { | ||
| long status = ((UInt32) signal.info.get("status").getValue()).longValue(); | ||
| long progress = 0; | ||
| Variant<?> progressVariant = signal.info.get("progress"); | ||
| if (null != progressVariant) { | ||
| progress = ((UInt32) progressVariant.getValue()).longValue(); | ||
| } | ||
| long nOps = -1; | ||
| Variant<?> nOpsVariant = signal.info.get("n_ops"); | ||
| if (null != nOpsVariant) { | ||
| nOps = ((UInt32) nOpsVariant.getValue()).longValue(); | ||
| } | ||
| long oP = -1; | ||
| Variant<?> oPVariant = signal.info.get("op"); | ||
| if (null != oPVariant) { | ||
| oP = ((UInt32) oPVariant.getValue()).longValue(); | ||
| } | ||
| String error = ""; | ||
| Variant<?> errorVariant = signal.info.get("error"); | ||
| if (null != errorVariant) { | ||
| error = (String) errorVariant.getValue(); | ||
| } | ||
| String errorMessage = ""; | ||
| Variant<?> errorMessageVariant = signal.info.get("error_message"); | ||
| if (null != errorMessageVariant) { | ||
| errorMessage = (String) errorMessageVariant.getValue(); | ||
| } | ||
| Progress p = new Progress(nOps, oP, status, progress, error, errorMessage); | ||
| for (ProgressListener listener : progressListeners) { | ||
| listener.onProgress(p); | ||
| } | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add type safety checks and reduce code duplication.
The direct cast without type checking could throw ClassCastException. Also, the code has repetitive patterns.
+private long extractLongFromVariant(Map<String, Variant<?>> map, String key, long defaultValue) {
+ Variant<?> variant = map.get(key);
+ if (variant != null && variant.getValue() instanceof UInt32) {
+ return ((UInt32) variant.getValue()).longValue();
+ }
+ return defaultValue;
+}
+
private void notifyOnUpdateProceeds(Flatpak.UpdateMonitor.Progress signal) {
- long status = ((UInt32) signal.info.get("status").getValue()).longValue();
- long progress = 0;
- Variant<?> progressVariant = signal.info.get("progress");
- if (null != progressVariant) {
- progress = ((UInt32) progressVariant.getValue()).longValue();
- }
- long nOps = -1;
- Variant<?> nOpsVariant = signal.info.get("n_ops");
- if (null != nOpsVariant) {
- nOps = ((UInt32) nOpsVariant.getValue()).longValue();
- }
- long oP = -1;
- Variant<?> oPVariant = signal.info.get("op");
- if (null != oPVariant) {
- oP = ((UInt32) oPVariant.getValue()).longValue();
- }
- String error = "";
- Variant<?> errorVariant = signal.info.get("error");
- if (null != errorVariant) {
- error = (String) errorVariant.getValue();
- }
- String errorMessage = "";
- Variant<?> errorMessageVariant = signal.info.get("error_message");
- if (null != errorMessageVariant) {
- errorMessage = (String) errorMessageVariant.getValue();
- }
+ long status = extractLongFromVariant(signal.info, "status", 0);
+ long progress = extractLongFromVariant(signal.info, "progress", 0);
+ long nOps = extractLongFromVariant(signal.info, "n_ops", -1);
+ long oP = extractLongFromVariant(signal.info, "op", -1);
+ String error = extractStringFromVariant(signal.info, "error");
+ String errorMessage = extractStringFromVariant(signal.info, "error_message");
Progress p = new Progress(nOps, oP, status, progress, error, errorMessage);
for (ProgressListener listener : progressListeners) {
listener.onProgress(p);
}
}Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In src/main/java/org/cryptomator/linux/update/FlatpakUpdater.java lines 195 to
226, the method notifyOnUpdateProceeds directly casts values from signal.info
without type checks, risking ClassCastException, and repeats similar code
patterns. Refactor by adding type checks before casting to ensure safety, and
extract the repeated pattern of retrieving and casting values from the map into
a helper method to reduce duplication and improve readability.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (4)
src/main/java/org/cryptomator/linux/update/FlatpakUpdater.java (4)
59-62: Avoid hardcoding the display parameter.The hardcoded
"x11:0"display parameter may not work correctly in Wayland environments or other display configurations.Consider obtaining the display parameter dynamically:
@Override public void triggerUpdate() throws UpdateFailedException { var monitor = getUpdateMonitor(); - portal.updateApp("x11:0", monitor, UpdatePortal.OPTIONS_DUMMY); + String display = System.getenv("DISPLAY"); + if (display == null || display.isEmpty()) { + display = System.getenv("WAYLAND_DISPLAY"); + if (display != null && !display.isEmpty()) { + display = "wayland:" + display; + } else { + display = "x11:0"; // fallback + } + } + portal.updateApp(display, monitor, UpdatePortal.OPTIONS_DUMMY); }
82-92: Improve exception handling in close method.The current implementation catches a generic
Exceptionand the logging could be more informative. Additionally, exceptions should not be swallowed inclose()method as perAutoCloseablecontract.@Override public void close() throws Exception { try { if (null != updateMonitor) { portal.cancelUpdateMonitor(updateMonitor); } portal.close(); - } catch (Exception e) { - LOG.error(e.toString(), e.getCause()); + } catch (DBusException e) { + LOG.error("Failed to close DBus connection properly", e); + throw e; + } catch (Exception e) { + LOG.error("Unexpected error during resource cleanup", e); + throw e; } }
124-135: Add type safety checks to prevent ClassCastException.The direct cast without type checking could throw
ClassCastException. Add proper type validation before casting.private void notifyOnUpdateProceeds(Flatpak.UpdateMonitor.Progress signal) { - long status = ((UInt32) signal.info.get("status").getValue()).longValue(); + long status = 0; + Variant<?> statusVariant = signal.info.get("status"); + if (statusVariant != null && statusVariant.getValue() instanceof UInt32) { + status = ((UInt32) statusVariant.getValue()).longValue(); + } else { + LOG.warn("Missing or invalid status in update progress signal"); + } + long progress = 0; Variant<?> progressVariant = signal.info.get("progress"); - if (null != progressVariant) { + if (progressVariant != null && progressVariant.getValue() instanceof UInt32) { progress = ((UInt32) progressVariant.getValue()).longValue(); } Progress p = new Progress(status, progress); for (ProgressListener listener : progressListeners) { listener.onProgress(p); } }
94-112: Handle monitor creation failure more robustly.The method can return
nullif monitor creation fails, which could causeNullPointerExceptionintriggerUpdate(). Additionally, only theProgresssignal handler is registered, missing theUpdateAvailablehandler mentioned in past reviews.-private synchronized Flatpak.UpdateMonitor getUpdateMonitor() { +private synchronized Flatpak.UpdateMonitor getUpdateMonitor() throws UpdateFailedException { if (updateMonitor == null) { var updateMonitorPath = portal.CreateUpdateMonitor(UpdatePortal.OPTIONS_DUMMY); if (updateMonitorPath != null) { LOG.debug("UpdateMonitor successful created at {}", updateMonitorPath); updateMonitor = portal.getUpdateMonitor(updateMonitorPath.toString()); try { + portal.getDBusConnection().addSigHandler(Flatpak.UpdateMonitor.UpdateAvailable.class, signal -> { + LOG.info("Update available signal received"); + // Handle update available notification if needed + }); portal.getDBusConnection().addSigHandler(Flatpak.UpdateMonitor.Progress.class, signal -> { notifyOnUpdateProceeds(signal); }); } catch (DBusException e) { - LOG.error(e.toString(), e.getCause()); + updateMonitor = null; // Reset on error + throw new UpdateFailedException("Failed to register DBus signal handlers", e); } } else { - LOG.error("Failed to create UpdateMonitor on DBus"); + throw new UpdateFailedException("Failed to create UpdateMonitor on DBus"); } } return updateMonitor; }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/main/java/org/cryptomator/linux/update/FlatpakUpdater.java(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: for the `freedesktopautostartservice` in the cryptomator project, exceptions are preferred to contai...
Learnt from: infeo
PR: cryptomator/integrations-linux#80
File: src/main/java/org/cryptomator/linux/autostart/FreedesktopAutoStartService.java:56-62
Timestamp: 2024-07-16T22:36:32.769Z
Learning: For the `FreedesktopAutoStartService` in the Cryptomator project, exceptions are preferred to contain all necessary debugging information without additional logging before throwing them.
Applied to files:
src/main/java/org/cryptomator/linux/update/FlatpakUpdater.java
| public FlatpakUpdater() { | ||
| this.portal = new UpdatePortal(); | ||
| portal.CreateUpdateMonitor(UpdatePortal.OPTIONS_DUMMY); | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Remove unnecessary monitor creation in constructor.
The constructor creates an update monitor but doesn't check or use the result. This monitor should be created lazily when first needed via getUpdateMonitor().
public FlatpakUpdater() {
this.portal = new UpdatePortal();
- portal.CreateUpdateMonitor(UpdatePortal.OPTIONS_DUMMY);
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| public FlatpakUpdater() { | |
| this.portal = new UpdatePortal(); | |
| portal.CreateUpdateMonitor(UpdatePortal.OPTIONS_DUMMY); | |
| } | |
| public FlatpakUpdater() { | |
| this.portal = new UpdatePortal(); | |
| } |
🤖 Prompt for AI Agents
In src/main/java/org/cryptomator/linux/update/FlatpakUpdater.java between lines
42 and 45, remove the call to
portal.CreateUpdateMonitor(UpdatePortal.OPTIONS_DUMMY) from the constructor
since the update monitor is created but never used there. Instead, implement
lazy initialization of the update monitor inside the getUpdateMonitor() method
so that the monitor is only created when first accessed.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (2)
src/main/java/org/cryptomator/linux/update/FlatpakUpdater.java (2)
41-44: Remove redundant monitor creation in constructor
portal.CreateUpdateMonitor(...)is invoked eagerly but its result is ignored and a fresh monitor is created later inprepareUpdate(), wasting a DBus round-trip. Drop this call and lazily create the monitor only when needed.
99-106: Handle potential DBusException fromupdateAppand make display selection dynamic
portal.updateApp(...)can throwDBusException; wrap the call in try/catch and fail the latch accordingly.- The display parameter is hard-coded to
"x11:0", which breaks on Wayland or non-standard X11 displays. Obtain it fromDISPLAY/WAYLAND_DISPLAYenv vars with a fallback.
🧹 Nitpick comments (1)
src/main/java/org/cryptomator/linux/update/FlatpakUpdater.java (1)
109-116: Null-safety for signal map access
signal.info.get("progress")is accessed without null-check before the cast at Line 114. Although unlikely, a missing key would raiseNullPointerException. Guard with a null check:Variant<?> progressVariant = signal.info.get("progress"); if (progressVariant != null && progressVariant.getValue() instanceof UInt32 u) { progress = u.doubleValue() / 100.0; }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/main/java/module-info.java(2 hunks)src/main/java/org/cryptomator/linux/update/FlatpakUpdater.java(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/main/java/module-info.java
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2024-07-16T22:36:32.769Z
Learnt from: infeo
PR: cryptomator/integrations-linux#80
File: src/main/java/org/cryptomator/linux/autostart/FreedesktopAutoStartService.java:56-62
Timestamp: 2024-07-16T22:36:32.769Z
Learning: For the `FreedesktopAutoStartService` in the Cryptomator project, exceptions are preferred to contain all necessary debugging information without additional logging before throwing them.
Applied to files:
src/main/java/org/cryptomator/linux/update/FlatpakUpdater.java
| @Override | ||
| public boolean isUpdateAvailable() { | ||
| var cdl = new CountDownLatch(1); | ||
| portal.setUpdateCheckerTaskFor(APP_NAME); | ||
| var checkTask = portal.getUpdateCheckerTaskFor(APP_NAME); | ||
| var updateAvailable = new AtomicBoolean(false); | ||
| checkTask.setOnSucceeded(latestVersion -> { | ||
| updateAvailable.set(true); // TODO: compare version strings before setting this to true | ||
| cdl.countDown(); | ||
| }); | ||
| checkTask.setOnFailed(error -> { | ||
| LOG.warn("Error while checking for updates.", error); | ||
| cdl.countDown(); | ||
| }); | ||
| try { | ||
| cdl.await(); | ||
| return updateAvailable.get(); | ||
| } catch (InterruptedException e) { | ||
| checkTask.cancel(); | ||
| Thread.currentThread().interrupt(); | ||
| return false; | ||
| } | ||
| } |
There was a problem hiding this comment.
Add timeout and proper version comparison in update check
isUpdateAvailable() blocks indefinitely on cdl.await() and sets the flag to true without validating that latestVersion is newer than the running one.
• Specify a sensible timeout (e.g. 30 s) and abort gracefully.
• Compare latestVersion with BuildConfig.version() (or similar) before returning true.
🤖 Prompt for AI Agents
In src/main/java/org/cryptomator/linux/update/FlatpakUpdater.java between lines
51 and 73, the isUpdateAvailable() method currently blocks indefinitely on
cdl.await() and sets updateAvailable to true without verifying if the
latestVersion is actually newer than the current version. To fix this, add a
timeout (e.g., 30 seconds) to the cdl.await() call to prevent indefinite
blocking and handle the timeout case gracefully. Also, modify the onSucceeded
handler to compare the received latestVersion string with the current version
from BuildConfig.version() (or equivalent) and only set updateAvailable to true
if the latestVersion is newer.
| portal.cancelUpdateMonitor(monitor); | ||
| stopReceivingSignals(); | ||
| portal.close(); // TODO: is this right? belongs to parent class. update can not be retried afterwards. or should each process have its own portal instance? | ||
| error = new UpdateFailedException("Update cancelled by user"); | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Portal lifecycle & resource leak
cancel() closes the shared portal, but the normal success path (applyUpdate) never does, leaving the DBus connection open for the lifetime of the JVM. Either:
• Make FlatpakUpdateProcess own a dedicated UpdatePortal and always close it in finally, or
• Let FlatpakUpdater implement AutoCloseable and close the portal when the application shuts down.
🤖 Prompt for AI Agents
In src/main/java/org/cryptomator/linux/update/FlatpakUpdater.java around lines
154 to 158, the shared portal is closed on cancel but not on successful update,
causing a resource leak. To fix this, either refactor FlatpakUpdateProcess to
own a dedicated UpdatePortal instance and ensure it is closed in a finally block
after update attempts, or modify FlatpakUpdater to implement AutoCloseable and
close the shared portal when the application shuts down, ensuring the DBus
connection is properly released in all cases.
Depends on cryptomator/integrations-api#62